-
Notifications
You must be signed in to change notification settings - Fork 8.2k
[Backport v4.0-branch] net: if: Release the interface lock early in IPv6 RS timeout handler #86737
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Backport v4.0-branch] net: if: Release the interface lock early in IPv6 RS timeout handler #86737
Conversation
|
@jukkar somehow missed this. Looking to merge in for the impending release but not passing CI. Can you take a look? |
|
Some Python PIP issue which looks unrelated issue to this PR. |
Add documentation for DAD start time variable as it was missing. Signed-off-by: Jukka Rissanen <[email protected]>
Add documentation for ACD timeout variable as it was missing. Signed-off-by: Jukka Rissanen <[email protected]>
The net_if.c:rs_timeout() is sending a new IPv6 router solicitation message to network by calling net_if_start_rs(). That function will then acquire iface->lock and call net_ipv6_start_rs() which will try to send the RS message and acquire TX send lock. During this RS send, we might receive TCP data that could try to send an ack to peer. This will then in turn cause also TX lock to be acquired. Depending on timing, the lock ordering between rx thread and system workq might mix which could lead to deadlock. Fix this issue by releasing the iface->lock before starting the RS sending process. The net_if_start_rs() does not really need to keep the interface lock for a long time as it is the only one sending the RS message. Fixes zephyrproject-rtos#86499 Signed-off-by: Jukka Rissanen <[email protected]>
In order to avoid any mutex deadlocks between iface->lock and TX lock, release the interface lock before calling a function that will acquire TX lock. See previous commit for similar issue in RS timer handling. Signed-off-by: Jukka Rissanen <[email protected]>
In order to avoid any mutex deadlocks between iface->lock and TX lock, release the interface lock before calling a function that will acquire TX lock. See previous commit for similar issue in RS timer handling. So here we create a separate list of ACD addresses that are to be started when network interface comes up without iface->lock held. Signed-off-by: Jukka Rissanen <[email protected]>
3e86312 to
0cbb687
Compare
|
I rebased on top of latest v4.0-branch and resubmitted, lets see what happens with CI now. |
|
@dkalowsk My rebase did not help, dunno what is going on here ¯\(ツ)/¯ |
|
215737c
into
zephyrproject-rtos:v4.0-branch



This is a backport of #86553 to v4.0. It does not have commit d5335d3 as the feature it is fixing was not present in v4.0
In order to avoid any mutex deadlocks between iface->lock and TX lock, release the interface lock before calling a function that will acquire TX lock. See previous commit for similar issue in RS timer handling. So here we create a separate list of multicast addresses that are to be rejoined when network interface comes up and then rejoin the groups without iface->lock held.
Fixes #86499